The present invention relates generally to the field of programmable logic devices and more particularly to an improved method for effecting operations on a plurality of in-system programmable logic devices.
IEEE Standard 1149.1 and 1a entitled IEEE Standard Test Access Port and Boundary-Scan Architecture, published Oct. 21, 1993 by the IEEE under ISBN 1-55937-350-4 relates to circuitry that may be built into an IC device to assist in testing the device as well as testing the printed circuit board in which the device is placed. In particular, the standard provides for testing IC devices connected in series (commonly referred to as a daisy chain or BSL chain).
FIG. 1 shows a system including three devices (devices 1 through 3) that are controlled by a test data input signal TDI, a test mode select signal TMS, and a test clock signal TCK, and generate a test data output signal TDO. The TDI signal entering the system is applied to device 1, which generates a test data output signal TDO that is applied to device 2, which in turn is connected through device 3 to generate the system TDO signal, thereby forming a daisy chain. All data and instructions for all devices are loaded into the data input port of device 1 and shifted into each device of the chain. This system complies with IEEE Standard 1149.1.
The test mode select signal TMS and the clock signal TCK control a 16-state state machine shown in FIG. 2 that is within each IC device, which meets IEEE Standard 1149.1, and controls shifting in of the data. On each rising edge of clock signal CLK; the state of test mode select signal TMS is inspected by a state machine within the IC device. (Such state machines are well known and are not discussed here.) FIG. 2 shows movement through the states based on the TMS signal at the rising edge of CLK. As shown in FIG. 2, five consecutive high (logic 1) TMS signals place the state machine into STATE 1, the Test-Logic Reset state. From there, a single low signal or a continuous low signal places the state machine into STATE 2, the Run-Test Idle state in which no action occurs but from which action can be initiated more quickly.
Loading data into the data registers of the devices will now be discussed. From STATE 2 (FIG. 2), a single logic 1 moves the state machine to STATE 3, the Select-DR-Scan state, which is a path select state from which loading of data registers can be initiated. One logic 0 signal initiates STATE 4, from which initializing data are loaded in parallel from an internal register. Next, a logic 0 signal initiates STATE 5, the Shift-DR state, which is held by logic 1 TMS signals while serial data are shifted into a shift register or registers. After serial shifting of data, a logic 1 followed by logic 0 causes a pause at STATE 7. Another 10 returns to STATE 5 for more loading of serial data. Following STATE 5 or STATE 7, two logic 1""s initiate STATE 9 in which the appropriate data registers are actually updated. While the state machine is in STATE 9, data that have been shifted into the IC are latched into the data registers on the falling edge of TCK. From here continuous high signals return the state machine to STATE 1, the Test-Logic Reset state, and continuous low signals return to STATE 2, the Run-Test Idle state.
Loading instruction data into the instruction registers of the devices will now be discussed. From STATE 2, two logic 1 signals prepare for capturing instructions into the instruction register by moving the state machine to STATE 10, the Select-IR-Scan state. A logic 0 then initiates STATE 11, the Capture-IR state, and a logic 0 then initiates STATE 12 in which instruction data are shifted into the instruction register while the TMS signal remains at logic 0. State 14 allows for a pause in the shifting of instructions into the instruction register, and STATE 16 causes the actual latching of the instructions into the instruction register, on the falling edge of TCK. Once the new instruction has been latched, it becomes the current instruction.
Programming, erasing, or reading back data from the devices will now be discussed. Some PLD devices are programmed by writing data into volatile memory cells, while other PLDs are programmed by writing data into nonvolatile memory cells such as EPROM cells or flash cells. Generally, these devices can be programmed using the IEEE standard discussed above. The programming step involves raising voltages at certain transistor gates to a high level and maintaining the high level until sufficient charge has flowed onto or away from a floating gate of the transistor to cause the transistor to maintain a certain state when the high voltage is removed. Typically, a stream of data from ten to several hundred bits long can be shifted into several devices in less time than is required to program a transistor (cell) in a device. Thus a practical and widely used programming procedure is to serially shift an instruction and then a unit of programming data through a daisy chain of devices (STATEs 5 and 12 of FIG. 2) and then move into a programming mode (usually occurs in STATE 2 of FIG. 2 when entered from STATE 9 or STATE 16) during which all addressed EPROM, EEPROM, or flash transistors (cells) are programmed simultaneously as specified by the programming data. This method is practical and efficient when all devices in the daisy chain are the same size and have the same requirements for programming time and programming voltage. However, the devices are often unequal in size.
Referring again to FIG. 1, configuration information (parameters) associated with each of the devices 1 through 3 is indicated for reference. For example, assume device 1 includes 500 addresses (#A=500), each address having a programming time TP=200 ms, where TP is the time required to program one address location. Device 1 also includes a four-bit data register 11 (RL=4) that stores shifted-in data for programming into a group of four bits associated with a selected address A0-A499 of device 1 includes four bits that are written from a four-bit data register 11. Further, device 1 includes an instruction register 12 for storing instructions shifted in the boundary scan chain. Assume also that device 2 has 1000 addresses, a TP=100 ms and an eight-bit data register 21, and that device 3 has 2000 macrocells, a TP=50 ms, and a sixteen-bit data register 31. Devices 2 and 3 have instruction registers similar to instruction register 12. The number of addresses defines the logic capacity of the PLD. During the programming process, configuration data representing one word (equal to the data register length) for each device is combined into a bit stream that is shifted into the data registers 11, 21, and 31 of the devices, and then programming is performed.
A problem with conventional programming tools is that the user is left to manually identify and arrange the configuration data associated with the devices of a system. This manual process is a problem because if the user misidentifies the order in which the devices are chained in the system, then, for example, 8-bit data intended for device 2 may be inadvertently programmed into eight bits of the sixteen bit data register 31 of device 3. When errors are made during this manual data entry process, the total programming time for programming the system shown in FIG. 1 is greatly increased, thereby increasing total manufacturing costs.
What is needed is an improved method of entering configuration data for in-system PLDS that avoids the costly errors associated with conventional methods.
The present invention is directed to a method for programming a series of in-system programmable devices that automatically generates device information files that facilitate fast and accurate programming of the devices, thereby greatly reducing the total programming time needed to program the system and reducing total manufacturing costs.
In accordance with an embodiment of the present invention, the method uses the Boundary-Scan IDCODE instruction to automatically read device identification codes from each device of a system. These device identification codes are then used to form a device information file that is used to collect and check the configuration data submitted for each device. In particular, the device identification codes are used to read device programming specifications from a centralized database, which are then stored in the device information field. When a device does not provide a device identification number in response to the IDCODE instruction, or when the database fails to provide specifications for a particular device, the user is prompted to enter device specification data that is automatically stored in the device information file (and, when a device identification code is available, in the centralized database for future reference). The user is then prompted to enter configuration data, which is automatically checked against the device specifications to make sure that the configuration data is entered correctly. Finally, when the configuration data is entered correctly, programming is executed using a selected programming tool. With the order of devices automatically set by the present method, proper sequencing of the configuration data during programming is assured. Accordingly, the method of the present invention greatly speeds up the configuration process while reducing the chances of incorrect sequencing the configuration data during the programming operation.